經過了監控系統的成功部署，小李的餐廳帝國在雲端運作得越來越順暢。但是，還有一個重大挑戰等著他們：如何將剩餘的傳統系統和資料庫搬遷到 AWS 雲端？
這天，小張找到小李：「我們的 EKS 監控系統運作得很好，但我注意到你們還有很多系統還在地端機房裡。是時候考慮全面搬遷到雲端了。」
小李皺著眉頭：「搬遷聽起來很複雜，而且風險很大。萬一搬遷過程中出問題，影響到營業怎麼辦？」
「這就是為什麼 AWS 提供了專門的搬遷工具，」小張說，「就像搬家公司有專業的搬家工具和流程一樣，AWS 也有一套完整的搬遷解決方案。今天我來跟你介紹這些工具，讓你了解如何安全、高效地進行雲端搬遷。」
小李在白板上畫出了他們現在的 IT 架構：
「我們現在有這些系統需要搬遷：」
「這些系統有些已經運行了 10 多年，有些還有複雜的相依性，」小李擔心地說，「我們要怎麼把它們安全地搬到雲端？」
小張在白板上寫下了「6R」：
「AWS 提出了 6R 搬遷策略，就像搬家時我們有不同的處理方式一樣：」
1. Rehost（重新託管）- 「直接搬家」
「就像把家具原封不動地搬到新房子，把現有的伺服器直接搬到 AWS EC2 上。」
2. Replatform（重新平台化）- 「換個更好的位置」
「保持應用程式不變，但使用 AWS 的託管服務，比如把資料庫搬到 RDS。」
3. Refactor（重構）- 「重新裝潢」
「重新設計應用程式，充分利用雲端的優勢，比如改用 Lambda 和 API Gateway。」
4. Repurchase（重新購買）- 「買新的」
「放棄舊系統，改用 SaaS 解決方案，比如從自建 CRM 改用 Salesforce。」
5. Retain（保留）- 「暫時不動」
「某些系統暫時保留在地端，等待合適的時機再搬遷。」
6. Retire（淘汰）- 「丟掉不要的」
「趁搬遷的機會，淘汰不再需要的舊系統。」
小李點點頭：「這樣分類很清楚。那我們應該用哪些工具來執行這些策略？」
「MGN 就像是專業的搬家公司，」小張解釋，「它可以幫你把整台伺服器『打包』搬到 AWS，而且搬遷過程中原本的伺服器還能繼續運作。」
小李好奇地問：「怎麼可能一邊運作一邊搬遷？」
「這就是 MGN 的神奇之處。它使用『持續複製』技術，就像一邊營業一邊裝修店面一樣。」
小張畫了一個圖解釋 MGN 的運作方式：
地端伺服器 ──→ MGN Agent ──→ AWS MGN ──→ EC2 實例
│ │ │ │
│ │ │ │
持續運作 持續複製資料 建立複本 準備切換
「整個過程分為幾個階段：」
階段一：安裝 Agent
「在要搬遷的伺服器上安裝一個小程式（Agent），它會開始複製資料到 AWS。」
階段二：初始同步
「第一次會複製所有資料，這可能需要幾小時到幾天，取決於資料量。」
階段三：持續同步
「之後只會同步變更的部分，保持兩邊資料一致。」
階段四：測試切換
「可以先做測試切換，確認一切正常。」
階段五：正式切換
「選擇合適的時間點，正式切換到 AWS。」
小張分享了一個實際案例：
「我之前幫一家公司搬遷他們的 ERP 系統。這個系統有 5TB 的資料，而且 24 小時不能停機。」
挑戰：
解決方案：
結果：
小李聽得很入神：「聽起來很厲害，但會不會很複雜？」
「其實操作很簡單，」小張說，「MGN 的介面很直觀，大部分工作都是自動化的。」
優勢：
限制：
「資料庫搬遷比一般應用程式搬遷更複雜，」小張說，「就像搬遷一個圖書館，不只要搬書，還要保持分類系統、索引系統都正確。」
小李想起他們的資料庫：「我們有不同類型的資料庫，Oracle、MySQL、SQL Server，它們都能搬遷嗎？」
「這就是 DMS 的強項，」小張說，「它不只能搬遷，還能在搬遷過程中轉換資料庫類型。」
1. 同質搬遷（Homogeneous Migration）
「從 MySQL 搬到 MySQL，從 Oracle 搬到 Oracle，保持資料庫類型不變。」
2. 異質搬遷（Heterogeneous Migration）
「從 Oracle 搬到 PostgreSQL，從 SQL Server 搬到 Aurora，改變資料庫類型。」
3. 持續複製（Ongoing Replication）
「搬遷完成後，可以持續同步資料變更。」
小張詳細解釋了 DMS 的工作流程：
步驟一：建立複製實例
「在 AWS 中建立一個專門負責資料搬遷的伺服器。」
步驟二：設定來源和目標
「告訴 DMS 資料要從哪裡搬到哪裡。」
步驟三：建立搬遷任務
「設定要搬遷哪些表格、如何處理資料轉換等。」
步驟四：執行搬遷
「開始搬遷，可以選擇一次性搬遷或持續同步。」
小張用小李熟悉的場景來解釋：
「假設我們要把你們的訂單資料庫從地端的 MySQL 搬遷到 AWS RDS。」
現況：
搬遷計劃：
第一階段：準備工作
1. 在 AWS 建立目標 RDS MySQL 實例
2. 設定網路連接（VPN 或 Direct Connect）
3. 建立 DMS 複製實例
4. 設定安全群組和 IAM 角色
第二階段：初始資料載入
1. 建立 DMS 任務（Full Load）
2. 開始複製歷史資料
3. 監控複製進度
4. 預計時間：24-48 小時
第三階段：持續同步
1. 啟用 CDC（Change Data Capture）
2. 持續同步新的訂單資料
3. 監控同步延遲
4. 驗證資料一致性
第四階段：切換
1. 選擇低峰時段（凌晨 2-3 點）
2. 停止應用程式寫入
3. 等待最後的資料同步完成
4. 修改應用程式連接字串
5. 重啟應用程式
6. 驗證功能正常
小李問：「如果搬遷過程中出問題怎麼辦？」
「這就是為什麼我們要做充分的測試，」小張回答，「而且 DMS 支援回滾，萬一有問題可以快速切回原系統。」
1. Schema Conversion Tool (SCT)
「當你要從 Oracle 搬到 PostgreSQL 時，SCT 可以自動轉換資料庫結構。」
2. 資料驗證
「DMS 可以自動比較來源和目標資料，確保資料完整性。」
3. 資料轉換
「在搬遷過程中可以進行資料清理、格式轉換等。」
4. 多目標複製
「可以同時複製到多個目標，比如生產環境和測試環境。」
「除了應用程式和資料庫，你們還有很多檔案需要搬遷，」小張說，「DataSync 就是專門處理檔案搬遷的工具。」
適用場景：
特色功能：
「如果你想要逐步搬遷，Storage Gateway 可以讓你的地端系統無縫使用 AWS 儲存服務。」
三種模式：
1. File Gateway
「讓地端應用程式透過 NFS/SMB 使用 S3 儲存。」
2. Volume Gateway
「提供 iSCSI 介面，後端使用 S3 和 EBS。」
3. Tape Gateway
「虛擬磁帶庫，讓現有備份軟體可以備份到 S3。」
「當你有很多系統要搬遷時，Migration Hub 可以提供統一的管理介面。」
功能：
小張強調準備工作的重要性：
「搬遷成功的關鍵在於充分的準備。就像搬家前要先整理、打包一樣。」
1. 系統盤點
- 列出所有要搬遷的系統
- 記錄系統規格和相依性
- 評估系統的重要性和複雜度
- 識別潛在的風險點
2. 網路規劃
- 評估頻寬需求
- 設定 VPN 或 Direct Connect
- 規劃 IP 位址分配
- 設定 DNS 解析
3. 安全考量
- 設定 IAM 角色和政策
- 配置安全群組
- 加密傳輸和儲存
- 合規性檢查
4. 測試環境
- 建立測試環境
- 進行搬遷測試
- 驗證功能正常
- 效能測試
1. 分階段搬遷
「不要一次搬遷所有系統，先從不重要的系統開始。」
2. 選擇合適的時間窗口
「選擇業務影響最小的時間進行切換。」
3. 準備回滾計劃
「萬一搬遷失敗，要能快速恢復到原狀態。」
4. 監控和驗證
「搬遷完成後要持續監控，確保系統穩定。」
問題一：網路頻寬不足
解決方案：
- 使用 AWS Snowball 進行離線資料傳輸
- 分批搬遷，避免網路壅塞
- 考慮升級網路頻寬
問題二：應用程式相依性複雜
解決方案：
- 使用應用程式發現工具分析相依性
- 按相依性順序進行搬遷
- 考慮使用容器化技術
問題三：資料一致性問題
解決方案：
- 使用 DMS 的資料驗證功能
- 實施資料校驗程序
- 準備資料修復計劃
小李關心地問：「搬遷會花多少錢？」
小張拿出計算機：「搬遷成本主要包括幾個部分：」
1. 工具使用費用
- MGN：按搬遷的伺服器數量計費
- DMS：按複製實例的使用時間計費
- DataSync：按傳輸的資料量計費
2. 資料傳輸費用
- 從地端到 AWS 的資料傳輸
- 跨區域的資料傳輸
- 網路頻寬成本
3. 暫時性資源費用
- 測試環境的 EC2 實例
- 額外的儲存空間
- 備份和快照費用
4. 人力成本
- 專案管理
- 技術實施
- 測試驗證
- 培訓成本
1. 選擇合適的實例類型
「不要一開始就選最大的實例，可以先用較小的實例測試。」
2. 利用預留實例
「如果確定要長期使用，預留實例可以節省成本。」
3. 自動化管理
「使用自動擴展和排程來優化資源使用。」
4. 監控和優化
「持續監控使用情況，及時調整資源配置。」
「搬遷完成只是開始，」小張說，「就像搬到新家後還要整理、裝修一樣，搬遷到雲端後還有很多優化工作要做。」
1. 效能調優
- 監控系統效能
- 調整實例大小
- 優化資料庫配置
- 改善網路延遲
2. 成本優化
- 分析使用模式
- 調整資源配置
- 使用成本管理工具
- 定期檢視和優化
3. 安全加固
- 檢查安全設定
- 更新安全政策
- 實施監控告警
- 定期安全審計
4. 災難恢復
- 建立備份策略
- 測試災難恢復程序
- 建立跨區域備份
- 文件化恢復流程
1. 雲端原生化
「逐步將應用程式改造成雲端原生架構，充分利用雲端優勢。」
2. 自動化運維
「實施 Infrastructure as Code，提高運維效率。」
3. 監控和告警
「建立完善的監控體系，及時發現和解決問題。」
4. 團隊培訓
「持續培訓團隊，提升雲端技能。」
搬遷計劃討論完後，小李若有所思地說：「我發現搬遷不只是技術問題，更是策略問題。」
小張點頭：「沒錯。搬遷是一個系統工程，需要考慮技術、成本、風險、時間等多個因素。」
「而且，」小李繼續說，「搬遷也是一個學習和成長的過程。通過搬遷，我們不只是換了個地方，更重要的是學會了新的思維方式和工作方法。」
如果你也在考慮雲端搬遷，記住這些要點：
1. 制定清晰的策略
2. 充分的準備工作
3. 選擇合適的工具
4. 重視團隊建設
5. 持續優化改進
「雲端搬遷只是數位轉型的第一步，」小張最後說，「真正的價值在於利用雲端的彈性、擴展性和創新能力，為業務創造更大的價值。」
小李望向窗外，彷彿看到了未來：「我已經開始期待我們全面雲端化後的樣子了。不只是成本節省，更重要的是我們能更快地響應市場變化，為客戶提供更好的服務。」
「這就是雲端搬遷的真正意義，」小張微笑著說，「不是為了搬遷而搬遷，而是為了更好的未來。」
這個故事展示了 AWS 搬遷工具的強大功能和實際應用。記住，成功的搬遷需要充分的準備、合適的工具、正確的策略，以及持續的優化。雲端搬遷不是終點，而是數位轉型旅程的新起點。
iThome鐵人賽
看影片追技術